Modern computer systems typically include several devices that communicate to each other over a bus. In some computer systems, multiple buses are required to allow efficient communication between all of the devices in the computer system. For example, a computer system may have several subsystems. The subsystems are interconnected through a first bus. In addition, each subsystem may have a subsystem bus to allow devices implementing the subsystem to communicate with each other. In such computer systems, a bus-to-bus bridge may be required to interconnect the first bus with a subsystem bus so that a device on the first bus may communicate with a device on the subsystem bus.
FIG. 1 is a block diagram of an exemplary system 100 with a first bus 101, a second bus 103 and a bridge 105 interconnecting the first bus 101 and the second bus 103. Several devices 107.sub.1 -107.sub.N communicate with each other over the first bus 101. Similarly, devices 109.sub.1 -109.sub.M communicate with each other over the second bus 103. The bridge 105 allows a device connected to the first bus 101 to communicate with a device connected to the second bus 103. In some applications, the bus 101 does not use the same protocols as the bus 103 and, thus, the bridge 105 must translate the communications from one bus in transferring the communication to the other bus. For example, such a bridge is disclosed in U.S. Pat. No. 5,522,050 entitled "Bus-to-Bus Bridge for a Multiple Information Handling System That Optimizes Data Transfers Between a System Bus and a Peripheral Bus", issued May 28, 1996 to Amini et. al., which is incorporated herein by reference.
FIG. 2 is a block diagram of an exemplary computer system 200 with a host bus 201 interconnecting a central processing unit (CPU) 203 and a memory 205. The CPU 203 is configured to access the memory 205 over the host bus 201. A host bridge 207 is connected to the host bus 201 to allow communication between the CPU 203 and devices connected to a peripheral bus 209. In this example, the peripheral bus 209 is a PCI (peripheral component interconnect) Local Bus. A more detailed description of the PCI Local Bus (hereinafter "PCI bus") is provided in "PCI Local Bus Specification Revision 2.1", published Jun. 1, 1995 by the PCI Special Interest Group, and which is incorporated by reference herein.
In this example, a PCI-to-PCI bridge 211 is connected to the PCI bus 209. It is understood that other PCI bus compliant devices can be connected to the PCI bus 209. The "PCI-to-PCI Bridge Architecture Specification Revision 1.0", published Apr. 5, 1994 by the PCI Special Interest Group, sets forth the requirements of a PCI-to-PCI bridge, and is also incorporated by reference herein. The bridge 211 includes a primary master interface state machine 213 and a primary target interface state machine 215, that adhere to the requirements of the aforementioned PCI Local Bus Specification. In addition, the bridge 211 includes secondary master and target interface state machines 217 and 219 for interacting with a second PCI bus 221. The state machines 213 and 215 are referred to as the primary interface state machines because they are connected to the PCI bus that is closest to the CPU 203. The state machines 217 and 219 are referred to as the secondary interface state machines because they are connected to the PCI bus furthest away from the CPU 203. As set forth in the aforementioned PCI-to-PCI Bridge Specification, the primary interface of the bridge 211 handles prefetch operations (described below in conjunction with FIG. 5) differently from the secondary interface.
FIG. 3 is block diagram illustrating some of the signals required by a device in order to communicate over a PCI bus. A PCI compliant device 300 includes at least: (a) thirty-two address/data (AD) lines for carrying thirty-two or sixty-four bit (requiring two address phases) addresses multiplexed with thirty-two or sixty-four bit data words; (b) four command/byte enable (C/BE#) lines for carrying four bit bus commands multiplexed with active low byte enable signals that indicate which bytes of the thirty-two bit data word are selected; (c) a parity (PAR) line for carrying a parity signal that implements even parity over the AD and C/BE lines of the previous clock cycle; (d) a cycle frame (FRAME#) line for carrying an active low signal driven by a bus master indicating the start and duration of a bus access; (e) a target ready (TRDY#) line for carrying an active low signal asserted by a target of a transaction when the target is ready to complete the data phase of the transaction; (f) an initiator ready (IRDY#) line for carrying an active low signal asserted by an initiator (i.e., a bus master) of a transaction when the initiator is ready to complete the data phase of the transaction; (g) a device select (DEVSEL#) line for carrying an active low signal driven by a device that has decoded its address as the target of a transaction; (i) a parity error (PERR#) line for carrying an active low signal asserted by a device that has detected a parity error during a data phase; and (j) a CLK line for receiving a clock signal from a clock generator (not shown). Of course, the signals shown in FIG. 3 are just some of the signals that can be implemented in a PCI bus.
FIG. 4 is a timing diagram illustrative of an exemplary PCI bus read transaction. Although PCI bus read transactions are well known, the following description is included for completeness. This exemplary read transaction uses thirty-two bit addressing and data. During the clock cycle 1, the initiating device asserts the FRAME# signal and drives a bus command (in this example, a read command) and address onto the C/BE# and AD lines, respectively. Thus, at the rising edge of the clock cycle 2, a valid bus command and address are available on the PCI bus.
During the clock cycle 2, the target device asserts the DEVSEL# signal. Thus, at the start of the clock cycle 3, the target device has acknowledged that it is the target. Also during the clock cycle 2, the initiating device asserts the IRDY# signal and the appropriate byte enable signals on the C/BE# lines. Consequently, by the start of the clock cycle 3, the initiating device has indicated that the initiating device is ready to receive the selected bytes of the first requested read data word. The initiating device has also generated the PAR signal with the appropriate logic level during the clock cycle 2 so that at the start of the clock cycle 3, the PAR signal, together with the logic levels of the bus command and address signals at the start the clock cycle 2, have even parity.
During the clock cycle 3, the target device asserts the TRDY# signal and provides the first requested data word on the AD lines. In a normal burst read transaction, typically, all of the byte enable signals are asserted. By the start of the clock cycle 4, valid data is available on the AD lines to be received by the initiating device.
During the clock cycle 4, the target device generates the PAR signal so that there is even parity when the PAR signal is taken together with the data and the bus enable signals at the start of the clock cycle (i.e., clock cycle 4). During the clock cycle 4, the initiating device asserts the appropriate byte enable signals for the second requested data word. In this example, the target device also deasserts the TRDY# signal during the clock cycle 4. Thus, at the start of the clock cycle 5, the PCI bus is in a wait state. During the wait state, the logic states of the AD signals, the C/BE# and the PAR signals at the end of the clock cycle 4 are extended through the end of the clock cycle 4 and into the clock cycle 5.
During the clock cycle 5, the target device asserts the TRDY# signal and provides the second requested data word on the AD lines. Thus, at the start of the clock cycle 6, valid data is present on the AD lines to be received by the initiating device, and valid byte enable signals are available on the C/BE# lines to be received by the target device.
During the clock cycle 6, the target device provides the third data word on the AD lines and provides on the PAR line the appropriate parity signal for the data and byte enable signals of the previous clock cycle. During the clock cycle 6, the initiating device provides the appropriate byte enable signals on the C/BE# lines for the third requested data word. Thus, at the start of the clock cycle 7, the target device has provided the third requested data word on the AD lines and the parity signal for the data and byte enable signals of the second data word.
In addition, in this example, the initiating device deasserts the IRDY# signal because it is not ready to accept the third data word. Thus, the PCI bus enters another wait state, which causes the initiating and target devices to extend the byte enable and the data signals of the clock cycle 7 through the leading edge of the clock cycle 8. The wait state also causes the target device to extend the parity signal generated for the third data word transfer through the clock cycle 9.
Also in this example, the second data word transfer included a parity error. As a result, the initiating device asserts the PERR# signal during the clock cycle 7 so as to be valid during at the start of the clock cycle 8. In accordance with the aforementioned PCI Local Bus Specification, the PERR# signal is asserted two clock cycles after the data transfer containing the parity error.
When the initiating device is on the primary PCI bus and the target device is on the secondary PCI bus, the PCI-to-PCI bridge operates ideally as follows. On the primary PCI bus interface, the PCI-to-PCI bridge provides the signals generated by the target device as described above in conjunction with FIG. 4. Conversely, on the secondary PCI bus interface, the PCI-to-PCI bridge provides the signals generated by the initiating device as described above in conjunction with FIG. 4. In addition, the aforementioned PCI-to-PCI Bridge Specification also requires that when the PCI-to-PCI bridge detects a data parity error, the bad data and bad parity must be passed to the opposite interface, if possible, to allow the parity error recovery mechanisms defined in the aforementioned PCI Local Bus Specification to operate.
Although the bridge 211 allows communication between devices on different PCI buses, a problem arises in generating the parity for certain prefetch transactions. For example, when the initiating device initiates a read transaction, the PCI-to-PCI bridge may be able to initiate a prefetch transaction on the target device's PCI bus. The PCI Local Bus and PCI-to-PCI Bridge Specifications define situations in which the bridge may prefetch read data on the target device's PCI bus. Because prefetching read data is typically faster than a normal read transaction, it may be advantageous to prefetch data on the target device's PCI bus even when the initiating device starts a read transaction selecting only certain bytes.
However, in prefetching data, all of the byte enable signals are asserted. Thus, the PAR signal on the destination PCI bus may have a different logic state than the PAR signal on the initiating PCI bus. If there is a data parity error on the destination PCI bus when the target device provides the prefetched data on the destination PCI bus, the PCI-to-PCI bridge must pass the parity error to the initiating device on the initiating PCI bus, pursuant to the PCI-to-PCI Bus Specification. Thus, the PCI-to-PCI bridge must not simply regenerate the parity signal when transferring the prefetched data from the target's PCI bus to the initiator's PCI bus because this scheme will not preserve parity errors on the target's PCI bus. Accordingly, there is a need for a PCI-to-PCI bridge that passes parity errors from the target device's PCI bus to the initiating device's PCI bus when prefetching read data.